In contemporary computing, computer application programs and other code may be downloaded and installed from the Internet. When downloading from an unknown or untrusted source, it is possible that such code is intentionally malicious or otherwise capable of harming or providing unauthorized access to important data. However, because there are many situations in which computer users benefit from the ability to download code and execute code without prompting, completely preventing downloading is not a practical solution to this problem.
Some environments, such as one based on Microsoft Corporation's .NET technology, attempt to solve the problems of running unknown or untrusted code by limiting what the code has permission to do. For example, the underlying platform can require that its callers have specific permissions, and while code can request the permissions it needs for the execution, the runtime will only grant permission to code based on policy that evaluates how much the code is trusted. Such permissions include things like the ability to access files and databases, connect to the Internet, interact with the user via a user interface, call into unmanaged code, and so forth. Prompting the user when a code requests such permissions is one policy-based solution, but is not very desirable because a typical user is often not equipped to make a correct security decision when prompted.
Writing secure code for platforms that enable applications to be downloaded and installed from the Internet without prompting is an extremely difficult problem. This is because the platform itself needs to have elevated privileges to properly operate. Security flaws can exist if any part of the platform code is written such that it inadvertently exposes a internal way to run untrusted code with elevated privileges, thereby allowing the untrusted code to perform unsafe operation. By way of example, the platform code needs to be able to call unmanaged code for operating system services, such as to render text on a window, while untrusted code is not allowed to do so, but if the platform code is inadvertently written such that the untrusted code can call unmanaged code via a call to a internal method of the platform code, a security flaw exists.
One solution that increases the likelihood that platform code that is securely written is to allow the developer to mark (e.g., using metadata) any part of the platform code that requires elevated permissions to run, or controls whether elevated permissions can be run, that is, the metadata indicates that the platform code is “critical” code that performs an unsecure operation. Security teams and static code analysis tools (e.g., FxCop is one such code analysis tool that checks .NET managed code assemblies) then recognize the metadata, whereby platform features can be developed so that the likelihood of platform code running with elevated privileges being exposed to untrusted code is dramatically reduced.
However, while highly valuable, the marking of such code and data as critical results in a complex code-review process that burdens a security team with many critical methods that need to be code reviewed. What is needed is a safe way to reduce the number of methods that need to be reviewed for criticality, as less-complex reviewing increases the likelihood that any security problems in the platform code will be found.